home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / bgpdepl / bgpdepl-minutes-92mar.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  10.8 KB  |  273 lines
  1. This is only a rough draft - Megan 04/20/92
  2.  
  3. The BGP Deployment Working Group Meeting Summary Report 
  4.  
  5. Agenda:
  6.  
  7.    o  BGP Deployment status and issues
  8.    o  Routing policy sharing mechanism 
  9.    o  Next Phase NSFNET architecture discussion
  10.  
  11. 1. BGP Deployment status 
  12.  
  13. There are more sites/regionals using BGP in production or testing since last 
  14. IETF meeting when the group started.  There are 22 regionals/sites (it was
  15. 8 last IETF) connecting to NSF/ANSNet are using BGP in production mode.  Most
  16. of them are using cisco BGP2 (BGP version 2) with their collocated NSS/ENSS.  
  17. Tow or Three sites are using gated with BGP1 or BGP2.
  18.  
  19. MILnet started beta test BGP3 on T-20 router.  There are 6 or 7 Milnet sites
  20. are using cisco to BGP3 with the T-20 router.  
  21.  
  22. The BGP pilot project for the Pan-European network (Ebone) is making progress.
  23. There are BGP peer sessions within European network.  There are also a lot BGP
  24. testing take place within European networks.
  25.  
  26.    New developments in BGP implementation:
  27.  
  28. Gated supports BGP2 and BGP3 now.  It is in alpha version.  CA*net is using
  29. this version to BGP2 with the NSS.
  30.  
  31. cisco has 9.0 beta which supports BGP2 and BGP3. 
  32.  
  33. Tony Li at cisco did an interoperate test between the cisco and other type of  
  34. routers with BGP implementation.  The result is listed in Appendix D.
  35.  
  36. Matt Methis of PSCNet gave a presentation of 'BGP Usage at PSC'.  His slides 
  37. are listed in Appendix C.
  38.  
  39. 2. Routing Policy Description Form
  40.  
  41. The Routing Policy sharing mechanism was discussed at the meeting.  The
  42. purpose of developing such mechanism is for each network sharing its routing
  43. policy to keep a global routing view so each network could design and   
  44. implement their policy routing to avoid inconsistent with the global routing.
  45.  
  46. We start with develop a routing policy description form.  It will be
  47. evolved to a information base to install these kind of information and make
  48. it available for general access.  It will also define the processor to
  49. process the information and generate inconsistency should it occur.  At the 
  50. meeting, an initial draft routing policy form was discussed and agreed upon.  
  51. The Routing form is included in Appendix B.  Merit will create a directory on
  52. host nis.nsf.net to install this form for anonymous ftp.  Merit will also
  53. create a mailing list for people sending the filled forms and install them 
  54. in the directory for anonymous ftp as well.
  55.  
  56. 3. The discussion of Future NSFNET backbone architecture and its routing
  57.    issues
  58.  
  59. Peter Ford led a discussion of the NSFNET recompetition architecture.  His
  60. report is included in Appendix A.
  61.  
  62. Appendix A.
  63.  
  64. NSFNET recompetition, architectural considerations.
  65. Reported by Peter Ford, LANL.  peter@lanl.gov
  66.  
  67. The National Science Foundation reported on architectural considerations
  68. for the NSFNET recompetition which will occur during the mid-1992.
  69. Leading the discussion were:
  70.         Robert Aiken (NSF)
  71.         Hans-Werner Braun (SDSC)
  72.         Peter Ford (LANL)
  73.         Stephen Wolff (NSF)
  74.  
  75. NSF expressed thanks to the many people who provided input into
  76. the process of developing an architectural model for the future NSFNET
  77. including Merit, the FEPG, the operators of the U.S. regional networks,
  78. the FARNET membership, and the Intercontinental Engineering and
  79. Planning Group members.
  80.  
  81. The architecture  discussion focused on an interconnection
  82. architecture for networks which either provisioned research and
  83. education networks or those who needed to connect to the
  84. research and education networks.  NSF stated that they believed that it
  85. is critical for the U.S. R&E networks get provisioned out of the
  86. growing telecommunications base so that they could take advantage of
  87. the economies of scale available in the telecommunications industry.
  88. This should allow for maximizing the flexibility in choosing
  89. within a parameter space defined by bandwidth, cost, reliability, etc.
  90.  
  91. The model was based on the notion of "network access points" (NAPs)
  92. which be a chunk  of shared media where networks (regionals, national,
  93. international, multination corporate, etc.)  could interconnect.
  94. The NSF will provide support for developing a management and routing
  95. coordination function at the NAPs.  This would be  done through
  96. a collaborative agreement under the name of "routing arbiter".  The
  97. routing arbiter would provide routing support at the NAPs through the
  98. use of a route server box which could peer with the attached networks
  99. and  send a "homogenized" picture of the routing topology dependent on
  100. the picture a network would want to see as previously negotiated with
  101. the routing arbiter.  The NAPs would be the focal point for
  102. evolving the internet architecture as new technologies became
  103. available and needed to be incrementally introduced.  The NAPs
  104. would be "NSF AUP free" so commercial traffic from a U.S. regional 
  105. could go onto the NAP in the process of going to another network 
  106. which carries commercial traffic.
  107.  
  108. There would be greater than 4 and  less than 17 NAPs and they would 
  109. be geographically dispersed.  The NSF recompetition will
  110. have  at least 2 providers for national scale R&E traffic   and they will 
  111. connect to all the NAPs.  The providers are free to connect to things
  112. other than NAPs, including regionals.
  113.  
  114. The was an extensive question and answer session, where the core 
  115. topics included:
  116.         asymmetric routes and the problems these posed 
  117.                 (Vince Fuller Stanford/Barrnet, Matt Mathis PSC, Milo
  118.                 Medin NASA)
  119.         the issue of who could connect to a NAP (Dan Long, John Curran
  120.                 BBN/Nearnet)
  121.         how the routing arbiter would be managed, with emphasis 
  122.                 placed on the observation that the current Merit/ANS/NSF
  123.                 configuration did not have the regional networks in 
  124.                 a position where they were the customers of the 
  125.                 NSFNET backbone (Scott Bradner, Harvard/Nearnet).
  126.                 Steve Wolff commented that he would like to hear
  127.                 input on this topic.
  128.         AUP issues
  129.         Would regionals have to connect to a NAP? -- no.
  130.         Overall management of the 2+ providers and the NAPs?
  131.  
  132. NSF also stated that the need for maintaining the routing 
  133. database that Merit currently manages would fall under the 
  134. auspices of the routing arbiter.
  135.  
  136. The session was well attended and the discussions were vigorous.  The 
  137. NSF would like to thank Jessica Yu for allowing them to barge into 
  138. the BGP deployment group meeting on short notice, and 
  139. would like to encourage any interested parties to contact the NSF  
  140. with ideas, questions, and concerns (steve@nsf.gov, raiken@nsf.gov, 
  141. peter@lanl.gov).
  142.  
  143. Appendix B.
  144.  
  145. Routing Policy Description Form  (4/6/92)
  146. -------------------------------
  147.  
  148. A. General Description of your Autonomous Systerm (AS) * 
  149.  
  150. a. List the name of your AS and the AS number(s) 
  151.  
  152. b. List the Routing administrator of the AS 
  153.         
  154.         Name:
  155.         Organization:
  156.         e-mail:
  157.         phone number:
  158.  
  159. c. List the networks that belong to your AS and mark them with RE or
  160.    non-RE type if applicable
  161.  
  162. d. List the name of your direct neighbor AS(s) and its AS number(s) 
  163.  
  164. e. List each IP address of your border router(s) which interface with your
  165.    neighbor border router(s) and the Exterior Routing Protocol(s) used
  166.    respectively. 
  167. f. Is your AS a
  168.                 Stub AS?
  169.                 Multi-homed Stub AS?
  170.                 Transit AS?
  171.                 Pure Transit AS?
  172.  
  173. g. List the IGP used within your AS (optional for a non-transit AS)
  174.  
  175. h. Describe the maximum and minimum bandwidth of the transit portion of your
  176.    AS (optional for a non-transit AS).
  177.  
  178. i. Describe the delay characteristic of physical links of transit portion 
  179.    of you AS, e.g., satellite, terrestrial (optional for a non-transit AS).
  180.  
  181.  
  182. B. Policy Descriptions 
  183.  
  184. a. For all the ASes.
  185.  
  186.         o Outbound advertisement filtering: 
  187.                 1. list the set of nets belong to your AS that you do
  188.                    not advertise to your neighbor(s). 
  189.                 2. list the set of nets belong to your AS that you
  190.                    do not wish to be advertised to certain ASs.  List 
  191.                    the AS numbers. 
  192.  
  193.         o Inbound acceptance filtering: list the set of ASs whose
  194.           nets you do or (do not) accept from your neighbor(s) 
  195.           If AS number is not a satisfactory granularity, list the
  196.           set of nets.
  197.                 
  198.         o Describe your routing policy based on your Acceptable
  199.           Use Policy (AUP): 
  200.                 Does your AS accept:
  201.                         1. all types of traffic? 
  202.                         2. only RE type traffic?
  203.                         3. other? (please specify)
  204.  
  205.         o Does your border router default to your neighbor border
  206.           router?  If yes, described the mechanism. 
  207.  
  208. b. For Multi-homed Stub ASes only:
  209.         
  210.         o List the preference/denial of the neighbor ASs which can
  211.         route your traffic to the same destination (Multi-homed AS only).
  212. c. For Transit AS only:
  213.         
  214.         o List the paris of source/destination ASs or nets that your 
  215.           domain does not provide transitivity. 
  216.  
  217.         o List the preference/denial of the ASs which can route your 
  218.           traffic to a certain destination.
  219. _____________________________________________________________________________
  220. Note: 
  221.  
  222. * The notion of Autonomous System(AS) here means the following:
  223.         a. An AS is a network blob which has a coherent Interior
  224.            routing plan and under single administration.
  225.         b. the AS number will be in the BGP AS path
  226.  
  227.  
  228. Appendix C
  229.  
  230. Matt Methis' presentation slide (Megan: it was sent you via Postoffice mail
  231. early this week, please insert it here.  Thanks!) 
  232.  
  233.  
  234. Appendix D 
  235.  
  236.                         BGP Interoperability Matrix
  237.  
  238. Versions tested:
  239. a) cisco 8.2,8.3 - v2
  240. b) cisco 9.0 (beta) - v2,v3
  241. c) BBN T/20 2.0 - v2,v3
  242. d) NSS/eNSS (???) - v1,v2
  243. e) gated 2.x - v1
  244. f) gated (alpha) - v2,v3
  245.  
  246.  
  247.    |   a   |   b   |   c   |   d   |   e   |   f   |
  248. ---+-------+-------+-------+-------+-------+-------+-----------------
  249. a  | same  |       |       |       |       |       |
  250. ---+-------+-------+-------+-------+-------+-------+-----------------
  251. b  | ok    | same  |       |       |       |       |
  252. ---+-------+-------+-------+-------+-------+-------+-----------------
  253. c  | ok    | ok    | same  |       |       |       |
  254. ---+-------+-------+-------+-------+-------+-------+-----------------
  255. d  | ok    | ok    | ?     | same  |       |       |
  256. ---+-------+-------+-------+-------+-------+-------+-----------------
  257. e  | vers  | vers  | ?     | ok    | same  |       |
  258. ---+-------+-------+-------+-------+-------+-------+-----------------
  259. f  | ok    | ok    | ?     | ok    | vers  | same  |
  260. ---+-------+-------+-------+-------+-------+-------+-----------------
  261.  
  262.  
  263. Status:
  264. ok - interoperability tested, found to work
  265. same - same version, interoperability assumed
  266. vers - lack common version
  267. ? - unknown
  268.  
  269. Tests:
  270. Establish connection.
  271. Negotiate version (if applicable).
  272. Exchange routes.
  273.